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It is impermissible to use the term “EMAIL”. 


Mail should be at least a mixture of upper and lower case. Devising your own font 
(Devanagari, pinhead graphics, etc.) and using it in the mail is a good entertainment 
tactic, as is finding some way to use existing obscure fonts. 


Sending the mail from Unix is frowned upon (although this has gotten much better). 


It is customary to attack the someone by including his or her message, indented 
(unless you are using MM), and replying point by point, as someone debating 
someone they are watching on TV, or hearing on the radio. 


It is considered artful to append many messages on a subject, leaving only the most 
inflammatory lines from each, and reply to all in one swift blow. The choice of lines 
to support your argument can make or break your case. 


Replying to one’s own message is a rarely-exposed technique for switching 
positions once you have thought about something only after sending mail. 


State opinions in the syntax of fact: “...as well as the bug in LMFS where you have to 
expunge directories to get rid of files.....” 


If you have nothing to say on a subject, replying with a line such as, “I agree with 
this.” puts you in the TO:’s for all future messages, and establishes you as “one who 
really cares”, if not an actual expert, on the topic at hand. 


Inclusion of very old messages from others makes for an impressive show. 


The choice of a subject line is of supreme importance. It should be concise and 
witty. The subject line has to survive once the discussion has diverged far past the 
original subject. Remember “Hewitt APO”? Oblique allusion to past famous subject 
lines is one of the best techniques for generating subjects. So is any reference to 
drawings of B. Kliban. 


People can be set wondering by loading obscure personal patchable systems, and 
sending bug reports. Who would not stop and wonder upon seeing “Experimental 
TD80-TAPE 1.17, MegaDeath 2.5..."2 The same for provocatively-named functions 
and variables in stack traces. 


Know the list of “large, chronic problems”. If there is any problem with the window 
system, blame it on the activity system. Any lack of user functionality should be 
attributed to the lack of a command processor. A suprisingly large number of 
people will believe that you have thought in depth about the issue to which you are 
alluding when you do. 


Know how to blow any problem up into insolubility. Know how to use the phrase 
“The new ~A system” to insult its argument, e.g., “I guess this destructuring LET 
thing is fixed in the new Lisp system”, or better yet, PROLOG. 


Never hit someone head on, always sideswipe. Never say, “Foo’s last patch was 
brain-damaged”, but rather, “While fixing the miscellaneous bugs in 243.xyz [foo’s 
patch], I found....” 


You get 3 opportunities to advertise your Rock band, no more. 


Idiosyncratic indentations, double-spacing, capitalization, etc., while stamps of 
individuality, leave one an easy target for parody. 


Strong language gets results. “The reloader is completely broken in 242” will open a 
lot more eyes than “The reloader doesn’t load files with intermixed spaces, 
asterisks, and The entire life, times, collected works, expressions, and modalities of 
Zippy the Pinhead are a common ground for much of the metaphor, rhetoric, and 
invective which pass daily through the mail. An occasional parenthetical “yow” 
CORRECTLY USED will endear one to the senior systems staff. So will puns and 
other remarks addressed directly to the point. 


